…ed changes

- Move painter-targeting CSS into BLOCK_TRACK_CHANGE_STYLES in the painter's
  styles module so document visuals live behind the painter boundary; keep
  contenteditable-side rules scoped under .sd-editor-scoped .ProseMirror tr.
- Drop stale isBlockLevel entries from previous state before merging in
  freshly-computed block entries, so accept/reject clears the bubble.
- renderDOM now emits data-track-change-id and data-track-change-operation
  alongside data-track-change so HTML round-trips preserve enough state for
  getBlockTrackedChanges and acceptTrackedChangeById to resolve the row.

Adds regression tests: stale-entry pruning in comments-plugin apply(),
renderDOM/parseDOM round-trip in blockTrackedChangeAttr, and a styles.ts
guard that fails if a bare [data-track-change=...] selector regresses.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ensions

Consumers (Superdoc Vue host, @superdoc-dev/react wrapper) take their
extension list from getStarterExtensions(); without this entry the new
block-level extension was exported but never loaded into the editor.

Updates the dedicated test that previously asserted opt-in-only behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The comments-plugin apply() reducer walked the entire doc for block-level
tracked rows on every tr.docChanged, even on docs that had no tracked rows.
Combined with in-place mutation of pluginState.trackedChanges and the
view.update decoration rebuild path, this created a stream of state
references that downstream consumers reacted to, contributing to focus
steal in side-by-side layouts where the editor sat next to an unrelated
input control.

Two structural changes:

- Track a hasBlockChanges bit on plugin state, computed once at init and
  refreshed only when a walk runs. Gate the block walk on
  (hasBlockChanges OR inputType='acceptReject' meta) so typing in a doc
  with no tracked rows never triggers the walk.
- Stop mutating pluginState.trackedChanges and pluginState.activeThreadId
  inside apply(); compute next-values locally and return them via the
  spread at the end. Plugin state must be treated as immutable across
  apply() per ProseMirror convention.

Adds regression tests that lock the gate (hasBlockChanges stays false
through typing, flips true once a tracked row appears).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ed editors

Track which DOMs the bridge has owned and only redirect keystrokes to a
stale ProseMirror[contenteditable=true] candidate if it is in that set.
Without this guard, an unrelated PM-based editor (Tiptap, Remirror)
mounted alongside SuperDoc would receive redirected input.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The WeakSet-based ownership check broke header/footer/footnote/endnote
accept/reject + undo (6 behavior tests in story-surface-tracked-change-decide):
story editors weren't registered in the bridge's owned set when sidebar
operations were the first interaction, so the bridge dropped the
stale-target redirect that those flows depend on.

Switch the check to a class-based ancestor lookup
(`closest('.sd-editor-scoped')`). Every SuperDoc editor — including
header/footer/footnote/endnote — is rendered inside a `.sd-editor-scoped`
container, so they're recognized without needing prior bridge activation;
foreign PM editors (Tiptap, Remirror, raw PM) are not, so the focus-steal
fix is preserved.

Bridge unit tests updated to wrap stale editors in a `.sd-editor-scoped`
ancestor (matches production DOM); foreign-editor regression test
unchanged (its `.tiptap.ProseMirror` element has no SuperDoc ancestor and
is correctly ignored).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds StructuralTrackChanges + computeStructuralDiff to the SD-3176
legacy-exports snapshot (intentional growth on superdoc/super-editor).
The named export is what consumers will import via:
  import { StructuralTrackChanges, computeStructuralDiff } from "superdoc";

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

When insertTrackedChange is called with from === to at a position
where bare text can't sit (e.g. at doc end past the last block), PM
auto-wraps the inserted text in the schema's required parents
(paragraph + run). The previous mark range used insertedNode.nodeSize
-- the bare text length -- which then covered the wrapper's open
tokens instead of the trailing characters of the actual text. Those
trailing chars escaped the trackInsert mark and survived accept/reject
as orphan text nodes (ALPMO-245).

Capture the doc size delta around the insert step and use it as the
mark range. addMark only attaches to text nodes inside the range, so
marking wrapper boundaries is a no-op there but pulls in the trailing
chars that PM's auto-wrap pushed out of the bare-nodeSize window.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Block-level diff replay sets `trackedChange` on a tableRow via the
StructuralTrackChanges extension. The three caches that drive painted
output -- the painter's per-page fingerprint in renderer.ts, the
measure cache in layout-bridge, and the canonical block version in
layout-resolved -- previously hashed only the cells, missing the
row-level attribute.

Result: applyHunks-style transactions that only mutated
`row.trackChange` reused stale cache entries, the page never
re-measured or repainted, and visible cells never received their
`data-track-change` attribute (so the row stayed unmarked until a
full scroll forced a remeasure).

Mirror the row.trackedChange fingerprint into all three caches so the
same transaction invalidates each one.

…print

computeStructuralDiff previously matched top-level blocks by
sdBlockId. That works in-process but breaks across imports: the docx
importer assigns a fresh sdBlockId on every load (there's no standard
OOXML attribute for tables to carry a stable id), so the AI-review
flow -- where the proposal is a separately-imported docx -- saw every
block as new and flagged the whole document as changed.

Switch the default identityKey to a normalized content fingerprint
(`${typeName}:${normalizedText}`) so identical blocks match across
imports. Document the limitations in the JSDoc: two truly-identical
blocks share a fingerprint and the algorithm treats them as one
(acceptable for current AI-review flow; consumers needing precise
duplicate handling can pass a custom `identityKey`). Consumers whose
proposal preserves sdBlockIds can opt back in via the option.

The block-level tracked-change shortcut in trackedTransaction applied
the original step as-is via `newTr.step(step)` but didn't call
`map.appendMap(step.getMap())`. In a multi-step transaction where this
shortcut fires before another step, the next iteration's
`originalStep.map(map)` then mapped through stale positions -- the
later step landed in the wrong place or got silently dropped when the
mapping returned null.

Matches the existing pass-through pattern in replaceStep.js where
applying a step as-is is always paired with `map.appendMap`. The
StructuralTrackChanges applyHunks path typically dispatches one step
per transaction, so the bug rarely hit today, but it becomes a real
correctness issue the moment two structural hunks share a transaction
or any other tracked change rides alongside a structural one.

`blockTrackedChangeAttrSpec.parseDOM` accepted nodes with
`data-track-change` set but `data-track-change-id` missing, producing
a `trackChange: { kind, id: null, operationId }` shape on the PM
node. That shape:

- can never be resolved by `applyRowTrackedChangeResolution`, which
  matches by id and would never find a null
- is already filtered out by `getBlockTrackedChanges` (so the entry
  is unactionable, just lingering as a no-op attr on the row)
- violates the documented `id: string` runtime type
- is asymmetric with `renderDOM`, which only emits
  `data-track-change-id` when `tc.id` is truthy — a faithful HTML
  round-trip always carries the id

Reject the missing-id case at parse time so the doc never holds a
half-formed trackChange shape.

…rmat

Upstream main introduced an OOXML-aligned shape for row tracked changes
(`attrs.trackChange.type === 'rowInsert' | 'rowDelete'`) and a
`buildRowTrackedChangeMeta` reader on the v1 layout-adapter that writes
the resolved metadata to `row.attrs.trackedChange`. Several of our
block-level pieces still spoke the older `{ kind }` shape and wrote to
the top-level `row.trackedChange`, so after the rebase onto main the
producer/consumer pair disagreed and painting silently no-oped:

  - `applyHunks` stamped `{ kind, id, operationId }` on the PM tableRow.
    The new reader (which keys on `type`) ignored it, so
    `row.attrs.trackedChange` was never populated. Switched to
    `{ type: 'rowInsert' | 'rowDelete', id, operationId, ... }`. Tests
    updated.
  - `comments-plugin` block-walk and `getBlockTrackedChanges` accepted
    only `{ kind }`. They now accept both shapes and emit the same
    normalized `kind` downstream.
  - `trackedTransaction.sliceContainsPreMarkedBlockTrackedChange`
    looked for `kind`; broadened to also detect `type === 'rowInsert' |
    'rowDelete'` so paste/replay slices skip double-tracking under
    either shape.
  - The legacy fallback path in `table.ts` (v1 layout-adapter) that
    populated the top-level `row.trackedChange` from the old shape is
    removed; `buildRowTrackedChangeMeta` is now the single producer.
  - The painter page-fingerprint, layout-bridge measure-cache, and
    layout-resolved canonical block version now hash
    `row.attrs.trackedChange` instead of the (now-unpopulated) top-level
    field, so applyHunks-style transactions invalidate the right caches.
  - `structural-track-changes` JSDoc refreshed to describe the new flow.

Net effect: a block-level diff replay now reliably paints the red/green
row decoration via the helper-based path (`applyRowTrackedChangeToCell`)
that upstream extracted.

Commit fff5326 ("invalidate row caches on tableRow.trackChange attr
changes") accidentally added a 738-line block to the bottom of the
painter's renderer.ts — a duplicate `deriveBlockVersion` implementation
plus supporting helpers (`getSdtMetadataId`, `hasListMarkerProperties`,
`hasVerticalPositioning`, etc.) that referenced names (`SdtMetadata`,
`TableAttrs`, `TextRun`, `ParagraphAttrs`, `getRunBooleanProp`,
`hashTableBorders`, `normalizeBaselineShift`, `applyRtlStyles`, …) which
were never imported into renderer.ts. The block was never called from
outside (`grep` confirms no external `deriveBlockVersion` reference in
the painter package), and the canonical `deriveBlockVersion` lives in
`layout-resolved/src/versionSignature.ts` which already has the
row-attrs.trackedChange hash from the audit commit. So the only effect
of the orphan block was to break `tsc -b` and the upstream CI build.

Truncate renderer.ts back to its upstream-main shape (last meaningful
line: `isNonBodyStoryBlockId`). The row-level cache invalidation
continues to work via `versionSignature.ts` and `layout-bridge/cache.ts`
(which read `row.attrs.trackedChange` correctly).

…tchet

Upstream's JSDoc ratchet (`packages/superdoc/scripts/check-jsdoc.cjs`)
requires every new public-reachable JSDoc file to either carry
`// @ts-check` or be on the allowlist. Our two new files
(`applyHunks.js`, `computeStructuralDiff.js`) tripped the gate and
broke the build stage on PR superdoc-dev#3343.

- Add `// @ts-check` to both files.
- Add a `StructuralHunk` typedef in applyHunks.js so the hunk array's
  properties (`changeId`, `kind`, `basePos`, `anchorBasePos`,
  `proposalNode`) are typed instead of the previous opaque `object[]`.
- Narrow `basePos` / `anchorBasePos` from `number | undefined` to
  `number` via runtime guards so the `tr.mapping.map(...)` calls
  type-check.

…o root exports

Surgical update to satisfy the export-snapshots gate (SD-3212 A0). CI
flagged drift in the runtime root exports — the two new named exports
from the structural-track-changes feature need to be in the snapshot's
import + require name lists.

Last commit's replace_all match also inserted computeStructuralDiff into
the types.import / types.require lists. It's a function (runtime export
only — has no separate type export), so the public-facade types facade
doesn't re-export it. Removing the type entries; the runtime
import + require entries stay.

…lass-based selectors

Upstream replaced the previous `[data-track-change='insert'|'delete']`
attribute selectors with class-based decoration (`.track-row-cell-dec
.track-insert-dec.highlighted` etc.) emitted by the new
`applyRowTrackedChangeToCell` helper. Our scoped-selector regression
test still asserted the old attribute form, so it tripped the unit
suite after rebase. Updated to assert the new row-cell class selectors
are scoped to `.superdoc-layout` — preserves the original intent (no
leaks into the PM mirror) against the current CSS surface.

Generalize the table-row block-tracking path to whole paragraphs so a
paragraph insert/delete is a reviewable structural tracked change
("remove the bullet points" -> reviewable paragraph deletions):

- paragraph schema spreads blockTrackedChangeAttrSpec
- applyHunks stamps a paragraph node directly, not just tableRow children
- acceptRejectRowTrackedChange resolves a top-level block (depth 0) without
  the $pos.before(0) "no position before the top-level node" crash
- layout-adapter projects the paragraph trackChange; DomPainter strikes the
  whole paragraph block

…tructural-row pipeline

PR-review feedback: this branch was building a parallel block-level
infrastructure (getBlockTrackedChanges, applyRowTrackedChangeResolution,
blockTrackedChangeAttrSpec, operationId, `{kind}` row attr shape) alongside
the existing structural-row pipeline (stampTableRows,
enumerateStructuralRowChanges, review-graph, decision-engine,
row-track-change.js OOXML import/export). Two parallel models could
disagree: an imported multi-row deleted table groups as one structural
change in the existing pipeline but as separate row entries in the new
one. Per ALPMO-... feedback, route everything through the existing
pipeline.

Changes:

- applyHunks now delegates to stampTableRows(). Same attribute shape
  ({ type: 'rowInsert' | 'rowDelete', id, author, authorId, authorEmail,
  authorImage, date, revisionGroupId }) end-to-end: OOXML import →
  enumerator → review-graph → decision-engine → OOXML export. The
  consumer (al-pmo) keeps its setStructuralDiff(hunks) entry point; the
  body just threads editor.options.user and a fresh ISO timestamp into
  applyHunks.

- structural-track-changes extension trimmed to one command,
  setStructuralDiff. acceptStructuralChange / rejectStructuralChange /
  acceptAllStructuralChanges / rejectAllStructuralChanges /
  acceptTrackedChangeOperation / rejectTrackedChangeOperation deleted —
  the review-graph projects whole-table structural changes into the
  unified decision model, so acceptTrackedChangeById /
  acceptAllTrackedChanges / their reject twins already cover this via
  dispatchReviewDecision.

- accept/rejectTrackedChangeById and accept/rejectAllTrackedChanges drop
  their block-level fallbacks. The "returns false on block-only changes"
  bug the reviewer flagged disappears with the fallback — we now just
  return reviewDecision.applied, which is true because the review-graph
  feeds structural changes into the decision engine.

- table-row.js dead-code bug (reviewer-flagged): the
  ...blockTrackedChangeAttrSpec spread was shadowed by the canonical
  trackChange definition below it, so the helper's parse/render were
  dead. Spread removed.

- paragraph.js: same spread removed. Paragraph-level structural revisions
  are an OOXML paragraph-mark primitive (w:rPr/w:ins), distinct from
  row insert/delete — per reviewer, split into a separate PR with its
  own design justification.

- comments-plugin block-bubble walk now consumes
  enumerateStructuralRowChanges (one entry per whole-table change keyed
  by stable structural id), replacing the manual descend that grouped
  by operationId. Same applies to the view-decoration handler.

- trackedTransaction pre-marked detector reads only the upstream type
  shape ('rowInsert' | 'rowDelete'); the legacy { kind } branch is gone
  because no producer writes that shape anymore.

- Public surface: enumerateStructuralRowChanges re-exported from
  @scale/superdoc so consumers (al-pmo) can iterate logical structural
  changes by their stable public id.

Deletes blockTrackedChangeAttr.js, getBlockTrackedChanges.js,
acceptRejectRowTrackedChange.js, blockTrackedChangeBubble.test.js, and
their tests. Net ~600 lines removed.

…itor exports

…table they replace

When a tracked-change AI edits an existing table in place, the resulting
proposal table has a different content fingerprint, so it is matched as
remove + insert rather than as the same table. The insert anchor used to
be the end of the last shared base block, which falls back to position 0
when the edited table is the first block — moving the new copy to the
start of the document, far from the original being struck through.

Switch to a lockstep two-pointer walk over base + proposal. When emitting
an insert hunk, anchor at the position of the next unmatched-base entry
(the block the insert is logically replacing), falling back to the end of
the last matched base block only when there is no waiting unmatched base.
Pure inserts and pure removes are unchanged.

Adds regression tests for editing the first table in a multi-table doc
and editing a later table with an intro paragraph.